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STAND-ALONE PROGRAMMING WORK-STATIONS 


Last month we discussed one type of programming work-sta- 
tion—host programming work-stations. These are software and 
firmware tools for use on in-house host computers. We described 
how users are obtaining increased programmer productivity and 
improved quality of programs through the use of these tools. 
This month, we look at a second type—stand-alone programming 
work-station systems. And we develop a checklist of system fea- 
tures which data processing management can use to better evalu- 


ate these up-and-coming products. 


P itiivisa Kellogg is  an_ international 
process engineering company, specializing in 
building oil refineries, fertilizer plants, and 
other large process control factories. It is a 
subsidiary of Pullman Inc. and employs some 
3500 people worldwide. 

Several years ago Pullman Kellogg central- 
ized its data processing operation at its head- 
quarters in Houston, Texas. There it uses the 
computer equipment of another Pullman sub- 
sidiary, Pullman Computer Services. Pullman 
Computer Services operates two computer 
centers in Houston, each with two IBM 370/ 
158s that use TSO and CICS. Kellogg has its 
own system development staff of 85 program- 
mers. 

After moving to Houston, the Kellogg pro- 
grammers were encouraged to use TSO for on- 
line programming. Management speculated 
that this would increase their programmers’ 
productivity by about 15% over their previous 
card and batch development environment. 

Well, the switch to TSO was successful—so 
successful in fact that, by early 1978, it had de- 


graded system response time badly. And their 
15% increase in productivity was evaporating. 
Programmers were waiting anywhere from 
three to twenty minutes to just sign onto the 
system. Also, TSO usage charges had grown 
rapidly. 

These factors prompted the lead technical 
support person to present the problem at a 
monthly ‘open forum’ meeting. These are 
meetings at which members of the department 
present and discuss current departmental prob- 
lems with the data processing manager. The 
discussion led to formation of a six-member 
team to investigate alternatives to TSO for on- 
line software development and maintenance. 


After several months of intermittant study, 
the team recommended acquiring a Four-Phase 
Programmer Workstation (PWS). PWS is a 
stand-alone programming work-station system. 
The prospect of off-loading all of their devel- 


- opment work, except compilation and testing, 


from the large IBM machines appealed to Kel- 
logg very much, particularly because of the 
large TSO costs they were encountering. 
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Kellogg was familiar with Four-Phase be- 
cause they had been using its data entry system 
for some time, and were pleased with it. So in 
September 1978 a twelve-station PWS system 
was installed. The system currently includes a 
Four-Phase IV/90 mini-computer with 192k 
bytes of memory, two 67.5 megabyte disks, 600 
and 1000 line per minute printers, a card 
reader and 15 display work-stations. 

Due to the large number of programmers at 
Kellogg, they decided to perform training in- 
house, and as quickly as possible. So the train- 
ing director held three two-hour sessions a day. 
With six programmers in each session, the en- 
tire department was trained in two weeks late 
last year. No further formal training has been 
needed. 

Migration from TSO to PWS occurred within 
two weeks, because the programmers preferred 
the rapid response time on the off-line system. 
And management was pleased with the cost of 
PWS. It has a fixed cost of about $1300 a week 
for twelve work-stations; the cost is not usage 
dependent like that of TSO. TSO usage dropped 
from 2,500 CPU minutes per week to about 5 
CPU minutes. Management also believes that 
they have regained their projected 15% in- 
crease in programmer productivity, and per- 
haps more. 

For software maintenance, PWS is used as 
follows. The programmer walks to one of the 
work-stations, which are located at different 
points in the department. After signing on, he 
or she uses a PWS macro command to create a 
copy of the source listing of the program he or 
she is to work on. The source code library is 
maintained on the mainframes by Panvalet, a 
program librarian package. Since this copying 
function may take anywhere from one minute 
to 15 minutes, the programmer signs off or 
performs other work on the work-station. 

When the program listing is available on 
Pws, the programmer makes the needed 
changes on-line using the system’s editing fea- 
tures. After these are completed, he executes a 
canned job control routine to compile and test 
the program on the target host, the IBM 370/ 
158. This PWS routine performs all of the nec- 
essary operations to place the job in the host’s 
RJE batch queue, return the run results to PWS, 
and place the program in Panvalet’s test li- 
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brary. The programmer can then view the re- 
sults of the test run on the work-station. 

For creating new programs on PWS, the pro- 
grammers often first retrieve strings of JCL in- 
structions, CICS maps for database use, or CO- 
BOL modules. Using these, they delete what is 
not needed, add new information, and thus 
more quickly create new programs. This proce- 
dure actually leads the programmers through 
the coding phase, so they tend to make fewer 
omission errors, we were told. 

Pullman Kellogg has not found it necessary 
to install work-stations in every programmer's 
office. They have found one work-station for 
every six programmers is sufficient. The pro- 
grammers readily share the work-stations and 
there is little waiting to use one. The people at 
Kellogg say this is because use of PWS makes 
coding and editing sessions shorter and more 
efficient than had been true using TSO. 

Pullman Kellogg is very pleased with their 
use of Pws. And their enthusiasm for the on- 
line approach is spreading to other Pullman di- 
visions. 


BNR INC 


BNR INC is a subsidiary of Bell-Northern 
Research Ltd., which has its headquarters in 
Ottawa, Canada, and is a research and develop- 
ment laboratory for Northern Telecom and 
Bell Canada. Bell-Northern Research is one of 
the largest telecommunication research labora- 
tories in the world, employing some 2800 peo- 
ple. BNR is located in Palo Alto, California, 
just south of San Francisco, and employs about 
300 people. BNR does telecommunication and 
automated office research. For example, they 
develop the software for computerized PBXs 
manufactured by other Northern Telecom sub- 
sidiaries. BNR has three DEC ppp 11/70s, one 
11/60 and one DEC 2050 on site. They also 
communicate to Bell-Northern Research’s IBM 
3033 in Ottawa over a leased line. 

In 1978 BNR wanted to increase computer 
support for its various programming projects. 
Since they were operating their equipment un- 
der the UNIX time-sharing operating system de- 
veloped by Bell Labs, and since they liked it 
very much, they became interested in a similar 
Bell-developed operating system, PWB/UNIX. 


This system is commonly called the Program- 
mer’s Workbench. 

The Programmer’s Workbench is based on 
UNIX. It contains most of the UNIX features and 
has enhancements designed specifically to sup- 

ort software development. Western Electric 
ee of the U.S. Bell family system, with no 
connection to Bell Canada or Northern Tele- 
com) licenses use of both UNIX and PWB/UNIX, 
but they do not support either system. So they 
allow their licensees to enhance, market and 
support both of these products. One such li- 
censee is Interactive Systems Corporation 
(ISC) in Santa Monica, California, near Los 
Angeles. 

In mid-1978 BNR decided to license use of 
Interactive System Corporation’s version of the 
Workbench (the 18/1 Workbench), because it 
could run on both their PDP 11/70s and their 
11/60. Further, they wanted ISC’s training and 
support for the system. 

BNR also installed some complementary 
products developed by ISC. One is INed, an en- 
hanced editing package that provides split 
screening, cut-and-paste operations, and full- 
screen editing. 

Another ISC product that BNR uses is the 
INtext terminal. When used with the INed 
package, most of the editing operations are 
carried out in the terminal processor, thus re- 
ducing the workload on the DEC mainframes. 
BNR has about 36 of these terminals and about 
65 other terminals to support 200 users. Some 
125 of these users are programmers; the other 
75 are office personnel who use only the word 
processing features of the systems. BNR has 
found the INtext terminals to be very cost ef- 
fective. They estimate that these have taken 
over about one-half of the work of their main- 
frames. 

A third complementary product is the re- 
mote job entry (RJE) sub-system. It handles the 
transmission of jobs to target systems. BNR 
uses the RJE facility to transmit jobs to the IBM 
3033 in Ottawa. 

Use of the Workbench for software develop- 
ment at BNR generally begins in the require- 
ments phase. BNR puts all requirements docu- 
ments on the system, using another product, 
INroff. INroff is a text formatting system for 
use with line printers, matrix printers, and 
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typewriter-like devices as well as typesetters. It 
allows users to define standard formats to be 
used for different types of documents. These 
formats can then be used by calling their ma- 
cro command names. 

BNR’s requirements documents have a stan- 
dard format, making them easier to review by 
the users—the engineers. And they are kept up- 
to-date with the system’s text editing features. 
On one project, the requirements document 
went through 15 iterations in just one day. The 
secretary was able to keep up with this pace 
using the system. 

BNR finds the Workbench to be a very so- 
phisticated programming tool. They took ISC’s 
four-hour training course, but some _ users 
found the system hard to use at first. Now, af- 
ter some months of use, they greatly appreci- 
ate its sophisticated features. 

One such feature is the Workbench’s com- 
mand language, known as the ‘shell.’ The shell 
is used for entering user commands to the UNIX 
operating system. In the Workbench, the lan- 
guage’s capabilities have been substantially ex- 
tended, making it convenient to use as a very 
high level programming language. The com- 
mands can be used alone, strung together on 
one line to form a very powerful sequence of 
operations, or combined with control com- 
mands to form shell programs. 

BNR programmers do a lot of shell pro- 
gramming, we were told. They create standard 
RJE JCL strings for the 3033 and place them in 
files. T. A. Dolotta, et al (Reference 1) point 
out that programmers who use the shell for 
this purpose make 20% fewer errors than those 
who write their own RJE JCL. 

These authors also point out that shell pro- 
gramming is often preferred by programmers, 
because the commands are quickly learned. 
Anyone who has used the UNIX system has 
learned some of these commands. And shell 
programming is fast, requiring much less hu- 
man effort than conventional programming 
languages do. If a program is going to be used 
a lot, it can be recoded in a more efficient lan- 
guage, after the shell program has proven its 
worth. For programs not run often, the origi- 
nal shell programs suffice. 

In at least one case, a BNR programmer has 
used the shell to write throw-away code for a 


significant application system—an_ in-house 
message system. The programmer wrote the 
programs using the shell commands. It was not 
a very efficient system to run, but it was cre- 
ated quickly. Then the system was used for 
about two months by some half dozen users. 
Their critiques were evaluated and the system 
was redesigned where needed. Then, it was en- 
tirely recoded in the language C, the UNIX sys- 
tem implementation language. And the old 
shell system was thrown away. The final system 
consists of 5000 lines of code, yet the entire 
project took only about four work-months of 
effort to complete. More importantly, the use- 
fulness of the new system was demonstrated 
one-fourth of the way through the project. 


Another feature of the Workbench that 
BNR uses a lot is the source code control sys- 
tem (SCCS). SCCS is a set of commands that is 
used to control changes to source code and 
files of text, such as manuals. Using it, versions 
of source code are tracked, along with the date 
of each change, who made each change, and 
why. The system stores the common code 
once, and the various versions separately, so 
that any version of a program can be recreated, 
as desired. BNR uses SCCS to track and control 
most of their software projects, so they have a 
complete history of each project’s work. 

From their use of the Workbench, the peo- 
ple at BNR have found that it has increased 
their productivity as well as the quality of their 
software. They think that because of its sophis- 
ticated features, the Workbench is aimed at 
people who use it constantly, such as program- 
mers. 


Two users of Pet/Maestro 


One of the leading programmer work-station 
systems has been developed by Softlab GmbH 
of Munich, Germany. In Europe, this system is 
marketed by Softlab under the name PET/ 
X1150, and it runs on the Philips x1150 mini- 
computer equipment. In the U.S., it is mar- 
keted by Maestro Systems, Inc., a subsidiary of 
Itel Corporation, under the name ‘Maestro.’ 
We will refer to the system as “Pet/Maestro.’ 


Since Pet/Maestro is among the most pow- 
erful of the programmer work-station systems 
and since the longest usage of this system has 
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been in Europe, we visited two organizations 
there to learn of their experiences. 


Vereins-und Westbank 


Vereins-und Westbank, with headquarters in 
Hamburg, is the largest regional bank is north- 
west Germany. The bank has 265 branches, lo- 
cated mainly in the northern part of the coun- 
try. At the end of 1978, deposits were almost 
DM 8 billion. 

Hamburger Dataverarbeitung GmbH (HDV) 
is the wholly-owned data processing subsidiary 
of Vereins-und Westbank. HDV provides data 
processing services not only for the bank and 
its branches but also for a number of bank cus- 
tomers. HDV uses an IBM 370/158AP, with 
24 Philips remote job entry terminals. There is 
a development staff of 65 people, the majority 
of whom are programmers. 

HDV has been a rapidly growing operation, 
and additional workspace has been needed al- 
most continually. So, for some years, the pro- 
grammers have not been located near the com- 
puter center, usually being 6 to 10 km away. 
Initially, source decks had to be transported 
physically, but for several years a remote job 
entry terminal had been used for communicat- 
ing with the host computer. But even with the 
RJE terminal, there still were problems. Turn- 
around was slow during peak periods, for in- 
stance, or the host might be down, etc. 

In early 1977, several of the managers at 
HDV saw an announcement of the new Pet/ 
Maestro system. They had been looking for an 
improved support tool for programming and 
had looked at IBM’s time-sharing option (TSO). 
But the operating system they were then using 
did not support TSO so that was not a solution 
they could use. They checked on the new Pet/ 
Maestro system, liked what they saw, and got 
HDV to enter an order for two systems. Each 
system was to have eight work-stations and 2.5 
million bytes of disk storage. These systems 
were installed in May 1977. 

The acceptance of these new systems was al- 
most immediate, we were told. All of the pro- 
spective users were given a four-day training 
course. Within two months, both systems were 
fully loaded and most of the programmers 
were asking for their own terminals. (A few of 
the programmers initially felt that the systems 


were downgrading them to ‘key punchers,’ but 
after some use, they changed their views.) 


So in October, 1978, HDV ordered three 
more Pet/Maestro systems, with a total of 50 
work-stations, and increased disk capacity to 
62 Mb per system. And in August of this year, 
they increased the total number of work-sta- 
tions to 68. 


Most of HDV’s existing applications are 
batch systems that have been written in assem- 
bler language. But new systems are being writ- 
ten in COBOL, and a growing number of them 
are interactive applications that use IMS. 


Use of Pet/ Maestro. HDV uses Pet/Maestro 
much Jike a typical on-line system—with some 
important differences based on features that 
Pet/Maestro offers. A text editor is provided, 
with which programmers enter and change 
lines of code. A library facility is included— 
with access control—for storing code in an ox- 
ganized fashion, for easy retrieval. A program- 
mer can copy sections of already-written code, 
or standard data definitions, into a new pro- 
gram. A reconstruct facility is provided, along 
with a number of other programming support 
features. In short, HDV uses an integrated set 
of functions, provided by Pet/Maestro, in the 
program development process. 


In addition to the various functions provided 
with the Pet/Maestro system, HDV has devel- 
oped about 55 procedures of their own, using 
the command language, for program develop- 
ment functions they desire. 


When a module has been coded, the pro- 
grammer instructs the Pet/Maestro computer 
to transmit the module to the host 370 system, 
on a remote batch basis, for compiling and 
test. The results are transmitted back to the 
Pet/Maestro system, often within 30 minutes— 
but turnaround may be in the order of two 
hours during afternoon peak load periods. The 
programmer can examine the results via the 
work-station, make any corrections using the 
text editor, and repeat the compile and test, if 
required. 


Other uses. This use of Pet/Maestro by pro- 
grammers is only part of HDV’s use of the sys- 
tems. As it was expressed to us, “We are using 
these systems almost as ‘automated office’ sys- 
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tems.” Here is a very brief summary of those 
uses. 

The systems are used by analysts and design- 
ers for storing requirements, specifications, and 
design statements, in text form. The text editor 
makes it easy to keep these statements up to 
date. 

Users can send messages from any work-sta- 
tion to any other, via the host. 

The systems are used for recording and 
keeping current certain management informa- 
tion, such as the organization charts, staff lists, 
job assignment lists, and so on. 

And the results of a business systems plan- 
ning (BSP) study made last year are kept in the 
systems. 


Some benefits. We asked about the benefits 
that have been obtained. Programmer produc- 
tivity has been improved by at least 20 to 30%, 
they estimate, both for maintaining and en- 
hancing existing systems as well as for develop- 
ing new ones. 

Pet/Maestro has removed some workload 
from an already loaded host Cpu. And by elimi- 
nating most of the syntax errors, it has cut 
down the number of compilations. 

The programming effort is now much less 
dependent on the host computer; it does not 
stop if the host is down. On the other hand, the 
programming effort is very dependent on the 
Pet/Maestro systems; if one of those is down, 
the people using it essentially stop work. 

But the overall impression we received is 
that HDV feels it is just beginning to exploit 
the capabilities of the Pet/Maestro system. 
Both as the system is enhanced by Softlab and 
as HDV extends its usage, benefits will con- 
tinue to accrue. 


Enka BV 


Enka is the largest division of Akzo NV, an 
international group of industrial companies 
that employs over 83,000 people world-wide. 
The group’s headquarters is in Arnhem, The 
Netherlands. The Akzo companies produce 
man-made fibers, salt, heavy and specialty 
chemicals, and other products. 

The Enka division produces most of Akzo’s 
man-made fibers, in the form of textile yarns 
and fibers, industrial yarns, and miscellaneous 


polymer products. The division has two main 
components—Enka AG in Wuppertal, West 
Germany (which is the division headquarters) 
and Enka BV in Arnhem, The Netherlands. 
We visited Enka BV to learn about their use of 
Pet/Maestro. 

Until early 1978, Enka used RJE terminals to 
communicate between the programmers and 
the Akzo IBM 370 host (now a 3033). Turn- 
around time for compilations and tests aver- 
aged between one and two hours. But there 
were the usual problems with this type of op- 
eration and the people at Enka were looking 
for better methods. 

So they began an investigation of the use of 
IBM’s TSO for on-line program development. A 
pilot project, involving four programmers and 
two terminals, was set up. While it was an im- 
provement, TSO still was not what they were 
seeking, they found; use of it required a good 
knowledge of the system, it was rather expen- 
sive, and response time varied from three sec- 
onds (acceptable, unless you are scrolling 
through files) to five minutes (completely frus- 
trating), depending upon the load on the host 
computer. 

Then in late 1976, one of the Enka software 
specialists saw a demonstration of the Pet/ 
Maestro system in Dusseldorf, Germany. He 
was impressed, but found that the system was 
not yet available in The Netherlands. In fact, it 
took Enka over one year to get their first Pet/ 
Maestro system. The first one was installed in 
Arnhem in February 1978, while the second 
was installed in Wuppertal shortly thereafter. 

The original system at Arnhem had 10 work- 
stations for a user group of 35 people. It was 
brought in for a trial period of three months. 
Softlab gave a three-day training course to the 
staff two weeks after installation, but by that 
time some of the staff had already learned to 
use it on their own. 

What was the response to the three-month 
trial? In the words of the software specialist 
we talked with, “We found that we couldn’t 
take the system out. Just about everyone was 
enthusiastic. I made a survey, and one of the 
responses was amusing. This programmer said, 
‘If anyone tries to take my terminal away, I'll 
kill him.’ Most of the other responses were just 
as positive but not that aggressive.” 
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In December 1978, Enka BV installed its 
second Pet/Maestro system and now has a to- 
tal of 16 work-stations. Enka AG has one sys- 
tem with 10 work-stations. 


Use of Pet/ Maestro. At Enka BV, system ana- 
lysts use Pet/Maestro for developing the speci- 
fications for a new system in text form. The 
top-down design features, plus the text editor, 
make it easier for them to correct and add to 
the specifications. Working from the specifica- 
tions, the programmers ther use the system’s 
interactive structured program design feature 
for developing program modules. 

With the structured program design feature, 
a programmer first indicates that he (or she) 
wishes to create a module. This starts a dialog 
between the system and the programmer. For 
each step, the system gives the programmer 
five choices: an action, a loop, the end of a 
loop, a branch point, or a case construction. As 
an example, the top level definition of a mod- 
ule might consist of the following series of 
statements: (1) Action—open personnel master 
file; (2) Action—validate file expiration date; (3) 
While—not at end of personnel file; (4) Case— 
(a) applicant resume received, (b) interview, (c) 
hire; (5) End while. The programmer would 
then go on to give more details for each of the 
three case situations. 

At this point, the programmer asks Pet/ 
Maestro to draw a ‘structogram’ of the logic. 
The structogram is a form of Nassi-Schneider- 
man diagram. It is usually printed out, so that 
the programmer can study it and go over it 
with the system analyst and, if necessary, the 
user. If changes are needed, they are made in 
the statements and the system draws new dia- 
grams. 

With the module logic developed, the pro- 
grammer then proceeds to code the module in 
COBOL and transmit it to the host for compila- 
tion and test. To aid in program development, 
Enka has created about 40 of their own macro 
procedures, in addition to the standard func- 
tions and procedures included in Pet/Maestro. 


Some benefits. It is hard to compare the new 
environment with the old one, we were told, 
because it is difficult to get comparable figures 
for the old situation. But the software special- 
ist we talked with had made a survey among 


the whole development staff. Following are the 
average estimates found from this survey. 
Overall programmer productivity has increased 
about 30%. For program maintenance, produc- 
tivity gains are even higher, in the order of 
40%, due to the ease with which changes can 
be made. Quality of the work done has in- 
creased, and users have estimated this increase 
to be 10% to 15%. The documentation is more 
complete and more up-to-date. And the system 
gives fast response. Independent of the number 
of users on it, the system gives a response time 
of between one-half and four seconds, depend- 
ing on what is asked of it. Users of Pet/Mae- 
stro are under no pressure, since “the meter is 
not ticking’ and the user can work at his/her 
own pace. Further, the (fast) system response 
time does not slow down the user. 


Programming work-station types 


To repeat ourselves a bit from last month, 
we define programming work-stations as those 
portions of computer systems that have been 
developed specifically for use by programmers 
for software development and maintenance. To 
use them, programmers work at work-stations, 
either CRT displays or typewriting terminals, 
rather than with pencils, coding sheets, cards, 
and paper listings. 

We see two main types of programming 
work-stations: host programming work-stations 
and stand-alone programming systems. 


Host programming work-stations, which we 
discussed last month, are software or firmware 
products designed to run on a company’s main 
computer. We described three such systems 
last month. One is aimed mainly at enhancing 
procedural programming, when conventional 
programming languages are used; it also sup- 
ports one non-procedural language. Another 
increases productivity through non-procedural 
programming, where the programmer specifies 
what needs to be done, rather than how it is 
done. The third system is a firmware system for 
a departmental-size mini-computer, to make it 
easier for the user department to develop pro- 
grams. 


Stand-alone programming systems, on the 
other hand, are devoted entirely to program 
development support. Programs developed on 
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these systems are generally intended to run on 
different machines, called ‘target systems.’ 

For a list of the products we found in our re- 
search, see Reference 7. 

Let us now look at stand-alone program- 
ming systems in more detail. 


Stand-alone programming systems 


Stand-alone programming work-station sys- 
tems are relatively new offerings. They are 
complete, stand-alone systems designed specif- 
ically to support software development. As 
such, the programs written using them are gen- 
erally intended to run on target machines. So 
these stand-alone systems require a communi- 
cation facility for sending programs to the tar- 
get computer for compiling and testing. 

Karl Drexhage, a management consultant 
who has had extensive experience with pro- 
gramming work-station use in Europe, points 
out in a paper (Reference 6) some of the bene- 
fits of stand-alone systems over host-resident 
systems. For one thing, he says, like distributed 
data processing, they shift work from a central 
computer onto a distributed computer—in this 
case, a dedicated development computer. And 
since development work no longer competes 
with production work for system resources, 
stand-alone systems give better response time. 
They give a low guaranteed response time—in 
the order of two seconds—while host system 
response times vary with the workload (and 
can become intolerably slow during peak us- 
age). 

Being off line, data security is better, he says. 
And these systems are more reliable since there 
are fewer parts to break down. They are de- 
signed for development work, so they are bet- 
ter human engineered. And stand-alone systems 
are lower in cost, because they eliminate the 
need for added memory, disk storage, commu- 
nication software, and terminals required for 
host-based systems. Finally, says Drexhage, 
they are host independent, so they can be used 
to develop applications for different hosts. 

Let us now look at the three stand-alone sys- 
tems mentioned earlier, in a little more detail: 
Pws from Four-Phase Systems, Programmer's 
Workbench developed at Bell Laboratories, 
and Pet/Maestro from Softlab GmbH in Eu- 
rope and Itel Corporation in the United States. 


PWS from Four-Phase Systems 


The Programmer Workstation (PWs) from 
Four-Phase Systems is a stand-alone system de- 
signed specifically to support software develop- 
ment for IBM System 360, 370, and 3000 Se- 
ries computers. Users can develop programs in 
any language that these target mainframes can 
compile. 

The typical basic system consists of a Four- 
Phase mini-computer with 96k bytes of mem- 
ory, a 67.5 megabyte disk drive, a 300 line per 
minute printer, a communication controller, 
and up to 16 display work-stations. It can be 
upgraded to 192k bytes of main memory, with 
other peripherals also added. 


To compile or test a program, the program- 
mer places the job and its associated JCL string 
into a PWS SEND queue. The system transmits 
the files over communication lines to a batch 
queue in the target mainframe. Following exe- 
cution, the mainframe sends the results back to 
the PWS printer. This output can then be re- 
trieved at the work-station. 


Pws allows editing in both command and 
full-screen modes. In the command mode, the 
cursor is outside the display window that con- 
tains the text. From here the user can type in 
commands to work on lines of text or entire 
files. The user can do such things as: (1) re- 
quest automatic tab settings and format con- 
trol for writing Assembler, COBOL, FORTRAN, 
and PL/1 programs; (2) search for strings of 
text, change and delete portions of the text, 
and then get successive occurrences of that 
string; (3) scroll forward one or ten records at 
a time; (4) perform functions on entire files, 
such as delete, rename, print, save, and queue 
for transmission; and (5) monitor the status of 
jobs sent to the target machine. 


In full-screen editing mode, the cursor 
moves into the 2l-line window containing the 
text. The user can directly edit the data using 
function keys. Pws also provides programming 
function menus of often-used functions. 


(Note that Pet/Maestro, which also runs on 
Four-Phase equipment, is a different system.) 


For more information on the Four-Phase 
PWS, see Reference 2. 
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Programmer's Workbench from Bell Labs 


As we have mentioned, the Programmer’s 
Workbench (technically named PWB/UNIX) is a 
time-sharing operating system developed at 
Bell Laboratories. It runs on DEC PDP-11 com- 
puters, models 45 to 70. (Some licensees have 
parts of it running on smaller DEC machines, 
we are told.) Also, Interactive Systems Corpo- 
ration (Reference 4) offers VAX/WB, to run on 
the DEC 32-bit VAX machine under the VMS 
operating system. 

Programs developed using the Programmer's 
Workbench can be targetted to run on DEC 
machines using UNIX, on IBM System/370, and 
on Univac 1100-series computers. Some licens- 
ees also include Burroughs in this list. The 
Workbench can act as either a stand-alone 
programming system or as a host system (for 
testing and compiling programs as well as run- 
ning production jobs). 

The Workbench contains a hierarchical file 
system of directories and files. Use of the files 
is very flexible and contributes to the Work- 
bench’s usefulness. There are nine file protec- 
tion modes possible—all combinations of read, 
write, and execute access, for three types of 
users: the file creator, a specific group of users, 
such as his project team, and all other users. 
The protection status of a file can be redefined 
by the creator at any time. 

We have already discussed the system com- 
mand language, the shell. Any program written 
using it can be named and used as if it also 
were a command. The output of one command 
can be connected to the input of another, so 
complex operations can be created by chaining 
together operations of simple programs. 

For example, there are shell commands 
which can: (1) search a file, or several files, for 
a given string of characters; (2) compare two 
files and list the differences; (3) check a file for 
mis-spellings; (4) format a file based on instruc- 
tions embedded in the test; and others. With a 
single command, a user can format a body of 
text, add line numbers, double space the text, 
and direct the result to an output device. 

The Workbench also includes powerful 
word processing functions, including text for- 
matting commands, spelling error detection, 
and numerous text editing functions, such as 


automatic pagination, hyphenation, right mar- 
gin justification, footnote placement, a multi- 
column page option, a table of contents gener- 
ator, and different paragraph styles. 

The BJE facility that we mentioned earlier 
makes the Workbench look like a card reader/ 
punch and line printer to the target machine. 
The RJE sub-system performs all of the func- 
tions necessary for communicating with the 
target, such as gathering together the necessary 
files, transmitting the job, receiving the com- 
pleted work, opening a new Workbench file 
into which this output is put, etc. 

Another feature of the Workbench is its two 
test drivers. These allow the system to simulate 
interactive terminals operating either on a Uni- 
vac 1100-series computer or an IBM System/ 
370. These are especially useful for complex 
testing situations, such as interactive database 
management and data communication opera- 
tions. 

For more information on the Programmer's 
Workbench see References 3 and 4. 


The Pet/Maestro system 


In our discussion above of HDV and Enka, 
we have given many of the characteristics of 
the Pet/Maestro system. So we will simply 
summarize here some of the key features of the 
system. For more information, see Reference 5. 

Pet/Maestro has been designed to run on a 
mini-computer, independent of the host com- 
puter for which programs are to be written. In 
Europe, Pet/Maestro is marketed by its devel- 
opers, Softlab GmbH, and runs on Philips 
X1150 equipment (actually a Four-Phase mini- 
computer). In the U.S., it is marketed by Mae- 
stro Systems Inc., a division of Itel Corpora- 
tion. It runs on Four-Phase equipment. (This is 
a completely different work-station system 
from the Four-Phase Pws, described above.) 
Pet/Maestro works with any host computer 
that supports a normal remote job entry proto- 
col, we are told. 

Each Pet/Maestro system can currently han- 
dle up to 20 work-stations. Each system is free- 
standing. Within one system, information can 
be transferred between work-stations. Commu- 
nications between work-stations on different 
Pet/Maestro systems are handled via the host 
computer. 
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Pet/Maestro supports program development 
starting with specifications and continuing 
through module design, coding, and testing. It 
allows programming in most of the popular 
languages, including COBOL, PL/1, FORTRAN, 
ALGOL, and others. Documentation can be 
both created and maintained throughout the 
process. 

To illustrate the use of Pet/Maestro, con- 
sider the case of the programmer writing a CO- 
BOL module. The programmer indicates that 
he/she wants to create a COBOL program, 
whereupon Pet/Maestro gives the list of the 
four COBOL divisions and asks which one is de- 
sired. Assuming that the procedure division is 
requested, and skipping some of the details, 
the system asks for the first verb (for the first 
statement). When it has been entered, the sys- 
tem gives a list of the options from which the 
programmer must choose, for that type of 
statement. The system then generates the fixed 
portion of the statement for the selected op- 
tion, and prompts the programmer for the var- 
iable information (data names, etc.). Because of 
this approach, very few syntax errors occur, we 
were told by users. When the coding has been 
completed, the programmer instructs the Pet/ 
Maestro computer to transmit the module to 
the host computer, on a remote batch basis. 

A text editor is provided for making addi- 
tions, deletions, changes, and global replace- 
ments in a body of code. But the text editor is 
also useful for handling textual information, 
such as narrative requirements statements, sys- 
tem and program specifications, and so on. 

A Pet/Maestro system provides a variety of 
functions to support the programming process. 
It encourages structured programming by pro- 
viding five control constructs for designing a 
program (action, loop, end of loop, branch, 
and case). It draws Nassi-Schneiderman dia- 
grams of the logic that has been expressed in 
terms of these control constructs. It allows for 
the easy marking of sections of code, text, and 
data—and these sections can be indexed. Mov- 
ing forward and backward, or from section to 
section, is done by one key stroke. A shorthand 
capability allows programmers to define their 
own abbreviations for often-repeated words, 
data names, and such; the abbreviations can be 
recalled by depressing a function key. The sys- 


tem allows users to easily copy selected por- 
tions of existing code into new programs that 
they are working on. An audit trail is kept of 
all changes to each program, which is becom- 
ing a necessity in some countries where new 
privacy laws require the ability to reconstruct 
a previous version of a program. 

In addition to these and other standard fea- 
tures, Pet/Maestro provides a procedure (or 
command) language whereby users can create 
their own functions. This language is easy to 
learn, we were told, but is a bit different from 
conventional languages; it uses pre-defined var- 
iable names, for instance. At Enka BV, a pro- 
cedure has been created for drawing flow- 
charts, for system and program design pur- 
poses. We saw a user create a 10-box flow- 
chart in less than one minute, as an illustration 
of the ease of use. 

Pet/Maestro provides project supervision 
support. It maintains statistics on how many 
lines of code have been generated and/or mod- 
ified by each system user, for instance. 

A decision table feature has been announced 
but had not yet been received by the users we 
talked with. With this feature, a programmer 
would build a decision table that gives pro- 
gram logic, in a dialog fashion. The system 
checks the table for incompleteness, redun- 
dancy, and inconsistency. 

Pet/Maestro has recently provided the ‘3270 
mode’ function. By using just one key, the Pet/ 
Maestro terminal can be converted to 3270 
mode, for operating with TSO—say, for on-line 
debugging on the host. The terminal can be 
converted back to Pet/Maestro just as easily. 


Checklist of features 


Judging from our brief product descriptions 
both last month and this month, it is quite ob- 
vious that no one system has every desirable 
feature. Such a system undoubtedly would be 
very expensive. And maybe having lots of “bells 
and whistles’ is not what every data processing 
department needs. 

To help data processing management better 
evaluate programming work-stations, we have 
compiled a fairly complete list of system fea- 
tures, compiled from existing systems. We sug- 
gest that management and programmers clas- 
sify these features in their order of importance 
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and then begin searching for a system that has 
the desired features. 

These then are the major features we found 
in programming work-stations, listed in alpha- 
betical order. 


Audit trails. Some programming work-sta- 
tions have facilities for keeping track of soft- 
ware changes. For those that do not, a source 
code library package can often be acquired to 
perform this function. These facilities have 
different features, and it is really up to each 
department to decide how elaborate a log of 
changes they want to keep. As mentioned, 
some new privacy laws require that a previous 
version of a program be reconstructable; audit 
trails make this requirement much easier to 
live with. 


Command languages. The most basic type of 
command (sometimes called ‘procedure’) lan- 
guage that we saw has 20 to 30 macro com- 
mands supplied by the vendor. These are gen- 
erally basic utility programs that can be called 
upon to run by using their names. Typical ones 
are sort, send output to printer, send job to 
mainframe, copy file, etc. 

Systems that provide these macro commands 
usually also allow users to write routines, give 
each routine a name, store it in a file, and in- 
voke it by calling its name. Another capability 
that may or may not be provided is the ability 
to string these commands together in a se- 
quence to form a macro procedure. 

On a more sophisticated level (and some 
users say a more useful level) are command 
languages with a hundred or more macro com- 
mands. They usually also contain control com- 
mands, thus becoming very high level pro- 
gramming languages. The commands generally 
are interpreted, not compiled, so they are not 
as efficient to run in a production environment. 
But they give very fast response time in a de- 
velopment environment. 


Communication links. During programming, 
project members will need to communicate 
with the host, with other team members, and 
possibly with other system facilities. For com- 
municating with the target computer, the 
stand-alone work-station systems should pro- 
vide the necessary links. They generally pro- 
vide two options, communication over tele- 
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phone lines or generating magnetic tapes. For 
communicating over telephone lines, these 
work-stations have a front-end communications 
controller, making them appear as remote 
batch terminals. Speed of transmission is im- 
portant because the communication task can 
tie up the work-station system and degrade ter- 
minal response. The RJE facility is necessary 
not only for compiling and testing programs 
but also for retrieving and sending programs to 
the source code library on the target. 


Message systems are a feature we think users 
will find most useful for keeping all team 
members equally informed. One system has a 
communication file capability built in. One 
line of the work-station display screen is re- 
served for use of this feature. Another system 
has a complementary message system package 
that can be added to it. 


Some systems have links to other features, 
such as typesetters, the corporate database 
management system, etc. 


Debugging aids. We saw a wide range of sys- 
tem capabilities aimed at reducing the amount 
of time programmers spend debugging pro- 
grams. 


For syntax corrections, some systems spot 
syntax errors and alert the programmer while 
code is being entered. Following compilation, 
one system automatically reports the probable 
location of the errors. And these features ap- 
pear easy to use. 


Several systems allow interactive debugging. 
That is, the programmer is alerted to an error 
during compilation or test execution, and he or 
she can correct the error and continue the test. 
Other systems do not allow this. Once a job is 
submitted, it is executed in the background 
mode and the programmer uses the work-sta- 
tion for other work. One person we talked 
with had doubts about the value of interactive 
debugging, saying that its overhead cost does 
not justify its usefulness for most programmers. 


For testing purposes all of the systems allow 
creating test data files which can be called up 
for testing. Seeing a demonstration of test data 


creation can help prospective users see how — 


much the editing and formatting features of 
each work-station help in this job. 
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One system contains test drivers for simulat- 
ing some interactive terminal situations. One 
driver simulates a Teletype cluster controller 
with up to four terminals, for testing programs 
on Univac 1100-series computers. The other 
driver simulates one or more IBM 3270 cluster 
controllers, each controlling up to 32 termi- 
nals. 


Conversational programmming aids. In con- 
versational programming, the system may help 
the programmer create conventional programs, 
by automatically generating formats, present- 
ing coding options, numbering lines, etc. We 
found conversational aids available for design- 
ing modules, writing program and control 
code, and for generating decision tables and 
structured flow charts. 


Design aids. All of the systems we saw have 
concentrated on providing programming aids. 
Most have not yet implemented graphical de- 
sign aids for system design. One system does 
have a graphic aid for program design. The 
system generates a type of structured flow- 
chart, based on a set of high level pseudo-code 
statements entered by the programmer. 

This system also prompts the users for creat- 
ing decision tables. And the system verifies that 
the table is complete, with no inconsistencies 
or redundancies. 


Documentation aids. All of the systems try to 
make it as easy as possible for programmers to 
include comment statements while coding, and 
to add and delete such statements afterward. 
Most systems provide formatting features, tai- 
lored to specific languages. Some systems have 
a HELP function, to aid programmers and end 
users when they do not understand a system re- 
quest. These are like on-line reference manu- 
als. 


Editing capabilities. The editing capabilities 
of the work-stations are the most obvious and 
often the most touted features. We found that 
the capabilities varied widely. 

The most easily used editing functions are 
those associated with function keys—that is, 
press the key and the function is performed. 
One system goes so far as to allow every key- 
board key to have a function, when pushed in 
conjunction with a function control key. An- 
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other has eight function keys along side the 
display screen, with the functions changing as 
needed. Most of the systems have special keys 
for common functions: cursor control, delete 
character, insert entry, etc. Editing functions 
not performed with keys are performed by typ- 
ing commands, such as global replace, search, 
copy file, change, etc. The systems varied in 
the number of such commands available. 

Additionally, some systems have some auto- 
matic editing features, such as punctuation, 
spelling and syntax error correction. 


Expandability. Two points should be men- 
tioned. One, there is a good chance that every 
programmer will eventually want his/her own 
terminal. This should be kept in mind when se- 
lecting a system. Secondly, for host systems, as 
terminals are added, the host will load up—and 
response times will suffer. Eventually, one or 
more stand-alone systems may be desired. 


Extensibility. The user should be able to add 
features not contemplated by the work-station 
designers, but essential for the user’s use. 
Check to see if you can add such features. 


File facilities. We found a great diversity in 
the file facilities of the various programming 
work-stations. As a baseline, all of the systems 
provide each programmer with: (1) a file area 
for keeping program modules, test data, job 
control instructions, etc., each with a name for 
easy retrieval; (2) a directory of accessible user 
files and publicly available files; (3) a work area 
for constructing new programs, editing old 
programs, debugging, etc.; (4) file protection 
features; and (5) file macro commands for ma- 
nipulating the library contents, such as copy 
file, rename it, delete it, and so on. Some sys- 
tems offer several options in each of these 
areas. 

Source code maintenance features vary in 
the systems also, from simple updating to 
keeping logs of program versions, specifying 
changes made, who made changes, etc. 

One last point about files and storage. Do- 
lotta, et al (Reference 1) note that all time 
sharing systems are continually short of disk 
space. And the RJE facility, which dumps a lot 
of information into a programming work-sta- 
tion rapidly, accentuates this problem. We no- 
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ticed that the users we visited opted for larger 
disk storage than the basic systems provided. 


Non-procedural programming features. In 
non-procedural programming the programmer 
concentrates on deciding what needs to be ac- 
complished, and the system generates the “how 
to do it’ code. Although this is not a new con- 
cept, it seems to be receiving more attention 
these days. Programming work-station systems 
may emphasize on-line non-procedural pro- 
gramming more and more. Two products that 
we saw offer this feature. 


Operating modes. Programming work-stations 
have several operating modes. The most obvi- 
ous is foreground versus background, which 
most have. In addition, these systems have var- 
ious specialized operating modes, such as a 
full-screen editing mode, command editing 
mode, debugging mode, etc. In some systems, 
these are treated as sub-systems. If the system 
has been poorly designed, the user must shift 
between these sub-systems too often. We be- 
lieve that it takes some use of a product, not 
just a demonstration, to decide whether it is 
easy or cumbersome to use. 


Programming aids. We have already men- 
tioned the most important programming aids: 
code format generation, syntax checking, se- 
quence numbering, structured programming 
diagrams, conversational programming, and 
non-procedural programming aids. 


In addition, some systems have added ‘bells 
and whistles’ aimed at the programming job. 
Here are a few of them: a MARK key, for mark- 
ing certain lines of code for future quick ac- 
cess; an ACCESS key, for moving to these 
marks; a user-created abbreviation file, where 
the user assigns abbreviations for frequently- 
used words and the system automatically 
makes the substitutions; a FIELD key, to move 
the cursor to the next field; and a permanently 
split screen, plus one line dedicated to system 
status and another to messages. 


Project management aids. We did not find 
too many built-in facilities to aid project man- 
agement specifically. But we would expect to 
see more project management aids in the fu- 
ture. 
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Recovery facilities. When an entire program- 
ming department becomes dependent on sys- 
tem operation to perform even routine work, 
then recovery facilities are important. One sys- 
tem we saw enters all input information onto 
the disk following each carriage return. This 
protects all but the current line from being lost 
if the system goes down. One user we talked 
with creates a backup disk every morning and 
a backup tape every week. 

Another type of recovery facility is one that 
helps a user recover after making an error. We 
saw two such facilities. One is an OOPS! key. It 
converts the last change made back to its origi- 
nal state. The other allows a user to retrieve a 
record that was just deleted. Such recovery 
procedures make these systems more ‘forgiv- 
ing’ and ‘friendly.’ 


Security features. Some of the users we 
talked with were very worried about program- 
ming work-station security features; others 
were not. Likewise with the systems, some 
have elaborate security features, others do not. 
File protection on the systems vary from (a) re- 
quiring a legal user identification and password 
in order to gain access to the system and all of 
its files, to (b) having several user-specified pro- 
tection levels for all files and programs. 


Target computers. The primary limiting fac- 
tor in selecting a programming work-station 
system is: Which ones work with our in-house 
computer? Most stand-alone programming 
work-station systems are aimed at specific tar- 
get machines; therefore, software developed on 
them can be compiled, tested and run on these 
targets only. 

These then are the main features that we 
think prospective users of programming work- 
stations should evaluate. 


We see the programming work-station field 
just beginning to emerge. The systems we saw 
appear to be a big move toward achieving 
greater programmer productivity. 

In the future we expect work-station en- 
hancements aimed at improving productivity 
in other phases of the software development 
cycle, such as the requirements analysis and de- 
sign phases. With these, data processing de- 
partments will finally be providing their own 
staffs with computerized tools as sophisticated 
as the ones they develop for others. 
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